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The requirements contained herein were drawn from two 
principal sources^ The contents of Section 6«1«3 were drawn from 
the documents submitted by the various Product Set and internal 
subsystem design groups as requirements on the Operating System. 
The contents of Section 6.1.7 were drawn from the IPL RAS 
Features document? dated 3/21/7^» submitted by V«0« Torres and 
J. A. Wilson. 
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The numbering conventions for the requirements set forth 
herein conform to the numbering system established in the IPL 
Requirements and Goals document* ' for major headings (Sections 
6.1.3.1 through 6.1.3.1^ and Section 6.1.7}. Minor headings are 
organized with the intent of indicating what area of the O.S. is 
affected by a particular requirement* and are uniform across all 
major headings. E.g. » minor heading>.3 under any major heading 
always indicates requirements on Record Management. 



1.2 V C 



The numbered outline is intended to be complete* to allow for 
future expansion. Therefore* some major headir>gs are listed as 
"To be supplied'** indicating that no requirements have been 
submitted by the applicable design group as yet. Some minor 
headings are followed by the statement "None"* indicating that 
although requiements have been received from the pertinent design 
group* none were identified as applying to this area of the O.S. 
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6.1.3 PRODUCT SET AND SUBSYSTEM REQUIREMENTS ON THE O.S. 
6*1*3*1 SHL 

6.1-.3.1.1 GENERAL REQUIREMENTS 

1. The object program makes the following assumptions when it 
receives control from the IPL environment. 

a. The stack segments and environment registers have been 
estabi ished. 

b. There is no support by the environment in case of a 
runtime abort. 

2. As far as can be determined* the primary user of Release 1.0 
will be the IPLOS project. 

3. Time of day* date* and interval timer services will be 
required. 

6.1.3.1.2 REQUIREMENTS ON SCL 
None 

6.1.3.1.3 REQUIREMENTS ON JOB MANAGEMENT 

1. Standard Accounting services will be required. ^ 

2. Standard Spooling services will be required. 
6.1.3.1.^ REQUIREMENTS ON DATA MANAGEMENT 

1. The object program must be able to output character and 
binary data in some form by August* 1975. 

2. There is no need to provide compiler support for SHL 
Input-Output for Release 1.0 as there will not be any IPLOS 
support for the I-O by the release date. 

3. The ability to write sequential legible and binary files 
from the simulator is a requirement in order to be able to 
record the results of test case execution. 

^. I/O interfaces for creating* opening, accessing* closing and 
deleting sequential and random text and binary files* and 
for supporting terminals are required. 

^.1.3.1.^ .1 Requirem ents on Volum e _ Manaqement 

None , 
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None 

None 
6.1.3.1,^.^ Reoulrements on BfocK Management 
None 

&Tll'?tl*'t^ Sjafl^Ir^tnaQTs,9n Pgvicg Privgrs 

No n e 
6.1.3.1.5 REQUIREMENTS ON PROGRAM MANAGEMENT 

1. There will be no special action taken to support the 
execution of SHL programs in multiple rings. The compiler 
will assume that the entire program will execute within a 
single ring. 

2. The operating system will be responsible tor the allocation 
of the stacK segment (s) for the program. It will also be 
responsible for setting up the canonical address registers 
and executing the initial procedure call to the SHL 
program. 

3. If coroutines are to be supportedf the operating system must 
provide a mechanism for allocating and freeing the stack 
segment(s) required for the coroutine. 

k» The operating system must take on the major responsibility 
for managing critical regions* shared-variable lockst 
events* event queues* the deactivation and reactivation of 
tasks* the stacking of soft-interrupts attached to event 
variables* and the activation of interrupt procedures. 

5. S hared vari a bles associated with critical regions are in the 
program's name space; however* their associated queues must 
be managed by the operating system. Locks on shared 
variables must also be managed by the operating system. The 
locks should be associated with descriptors established in 
system storage by the loader. 

6. Some mechanism for determining the ownership of locks on 
shared variables ("signatured locks") is required to keep a 
process from sta 1 1 Ing itsel f . 

7. E vent variables must be shared between processes (but should 
not be shared variables associated with crit ica l r e gions) . 
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Event variables must be In the system name space* and be 
capable of being established at run time. However* it is 
not necessary thslt all event primitives be implemented by 
system calls. The object program could interrogate the 
status of event variables to determine whether or not a 
system call was necessary. 

8. Tasks are characterized oy a procedure and an associated 

l55li Ji5!li3blfi. L^inzh procedures can be executed 

asynchronously; cr^t ig^l procedures can exist only in one 
process at a time. Global variables are all shared; 
critical procedures may have local static variables that are 
not ghgrgj. The operating system is responsible for all 
synchronization and stack management. 

9. Although task variables are in the program name space* they 
are associated with task-control -blocks (at least, for 
asynch procedures) some of whose elements are within the ken 
of spawner and spawned. References to these are "qualified" 
by the task variable* which requires the generation of an 
associated entry into the system name space at execution 
t i me . 

10. Critical procedures require a signatured lock to ensure 
that they exist in*' and only in* the calling process. 

11. The stack frames associated with the spawning process and 
with the asynch or critical procedure are critical in that 
their associated blocks cannot be terminated until all 
processes depending on them have terminated (alternatively* 
termination attempts should result in the termination of 
subordinate processes) • 

12. The operating system is responsible for initializing and 
handling stack forks. Operating system support may be 
required to monitor r eturns , exits and go-to ^ across stack 
forks and critical frames in general. 

13. The conventional mechanism for conmunication and 
synchronization between the simple kinds of asynchronous 
processes cited above is the conventional message buffe r, 
which is the only variable that is shared. The exclusion 
of these should be reconsidered. 

1<». Soft interrupts and faults result in procedure calls. When 
an interrupt is caused or a fault is sensed* the state of 
the interrupted process must be saved in the process stack 
and a call to the handling procedure generated Just as 
though the call had actually occurred in the interrupted 
process. ' 

15. The operating system is responsible for: attaching and 
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detaching interrupts; queuing and handling of the 
associated event variables* determining when an interrupt 
procedure is enabled or disabled - and activating or 
queuing accordingly* 

16« The operating system is responsible for fielding, all 
faults* determining wnether or not the fault is enabled^ 
and activating the currently attached fault procedure. The 
system fault-handler* itself called as a procedure* must 
disengage itself dnd activate the currently attached fault 
procedure as though the fault procedure had itself been 
called from the interrupted process when the fault was 
sensed. 

17. Interrupt and fault procedures may be parameterizedi in 
general* interrupt procedures waiting on aiy and all events 
must be notified of which event triggered them; similarly 
for a fault procedure attached to any and all faults. 
Fault-specific parameters will probably be required* and 
interrupt procedures requiring more Information may be 
needed. 

18.. Information about the existence and status of Interrupt and 
fault procedures must be Kept on the process stacK. This 
implies that the operating system can be cognizant of stack 
structure and that all processes (whether SHL-compiled or 
not) use a stack. 

19. Stack initialization and allocation is required. 

20. Allocation of stack space on and after procedure calls will 
be handled by compiled-out code sequence. 

21. Traps on references outside of allocated stack space are 
required. 

22. Stack underflow and overflow require special handling; they 
are exceptions to the rule of handling fault procedures in 
the user's stack. 

23. Coprocesses are synchronous processes with their own 
stack. The establishment and switching of stacks 
associated with coprocess control should Q2l require 
excursions to the operating system. 

2^. Standard error and exception handlingi set* reset* simulate 
traps and interrupts; attachment and detachment of 
exception- hand I ing procedures are required. 
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6.1.3.1.6 REQUIREMENTS ON STORAGE MANAGEMENT 

1. ■ Standard segment creation* limit management* and deletion 

are required. 

2. Standard storage and working-set management Is required^ get 
and free pages; specification of 'sticky* parts; overlay 
control . 

3. Special handling of allocated pages to minimize page-fault 
Interference on references to allocated but unaccessed pages 
would be desirable. 

6.1.3.1.7 REQUIREMENTS ON SYSTEM MANAGEMENT 

1. The project must be able to link* load* and execute ob|ect 
decks by June* 1975. 

2. The use of some form of IPL linking loader is a requirement 
to link separate SWL compilation and runtime procedures 
together for execution. 

3. We need such facilities as type checking across procedure 
calls. It seems that the Loader is the appropriate place to 
perform that task for all languages provided that it is 
possible to specify the severity of a type conformity 
error. 

The following are all requirements on the loader. 

'f. Policing of x^sizXtai type matchingst shared type raatchlngs* 
and parameter type matchlngs accross separately-compiled' 
modules* these may be either data or program types. 

5. Handling and policing of extepngL variables. 

6. Establishment and initialization of locks^on shared 
variables and even t variables. 

7. Packaging of Code sections* binding sections and* possibly* 
static sections for future linking. 

8. Handling of context tables in such packagings. 
9.' Handling of full length SWL identifiers. 

10. Establishment and initialization of static sectionCsl and 
system heap. 

11. Establishment of both SWL-local and global segments*. 

12. Establishment* and possible allocation and Initialization, 
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of stack segments. 

13« General handling of object I ibrarles« 

1^« Initiallzationy handling of local segments and 
establishment of context-table connective tissue for 
debugging could be handl ed by a capability for calling 
user-supplied procedures during loading* The cost for. 
installing such a test on the loader might be preferable to 
burdening the loader with detailed Knowledge of mapping 
functions* object structures and idiosyncrasies of all 
possible languages. 



6.1.3.1.8 REQUIREMENTS ON DCS 



1. 



Standard 
required. 



Operator Communications services 



Hill 



be 



SijlIjlIjlZ^QSI^QL 



6.1.3.2.1 GENERAL REQUIREMENTS 



1. A Message Control System CMCS) Is definitely needed* 

2. The same general f aci 1 1 ties as In the ATG proposal wl M be 
needed by COBOL by the time the product is released. 

3. The IPL COBOL compiler group anticipates a symbolic dump 
will be needed by the COBOL programmer as a supplemental 
debugging aid. Object code is not to be presented to the 
user since a high level I anguage user has no interest In 
such detail. 



The COBOL compiler should be able to provide (on request* 
perhaps) the following dumping Information as part of the object 
code files 

1. Symbolic data names 

2. A description of each data area! 

a. memory address (PVA format) 

b. length 

c. data type 

d. decimal position (If applicable) 

e. number of occurrences of an ltem"'lf subscripted 

A dump Is usually viewed as a system function* and so the IPLOS 
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group should state Its position on this matter. 

6.1.3.2.2 REQUIREMENTS ON SCL 
None 

6.1.3.2.3 REQUIREMENTS ON JOB MANAGEMENT • 

1. The minimum O.S. support required for data recovery Is a 
checkpoint/restart facility to support the RERUN statement. 
It is permissible to require that this function be specified 
outside of the source program. If a superior recovery 
facility is not specifiable outside of the source program* 
however, then the COBOL RERUN facility must be supported. 

6.1.3.2.^ REQUIREMENTS ON DATA MANAGEMENT 

None 

m ents on Volume Management 



6.1.3. 2 
None 



1. 



2. 



3. 



Support of the 3 file organizations (sequential* relative 
and Indexed) Is absolutely required. 



Indexed. file organization must support the existence 
several (alternate* not multiple level) Indices. 



of 



5. 



The relative file organization "relative key" requires the 
same treatment as the Indexed file organization "prime key". 

It is required to allow program access to all labels* user 
and system labels (for security reasons* certain fields of 
the system labels might have to be blank filled before the 
label contents are passed to the program). Label processing 
Is planned for all file organizations* not only for 
sequential files* at OPEN and CLOSE time (beginning and 
ending file labels) and at beginning and end of volumes. 

An OPEN of an unavailable file should not automatically 
discontinue the program; it should put it in a WAIT status* 
if the OPTIONAL clause is not present* and output a message 
requesting the file from the operator or the terminal user; 
It should return an OK status If the OPTIONAL clause Is 
present. The Operating System should also be able to 
recognize al I labelled files and attach them automat i-ca 1 1 y at 
OPEN time. 
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6« The .Operating System should close all unclosed files 
attached to a given job when this job reaches end-of-Jobt 
whether this is due to a STOP RUN or a Job termination by the 
operator or the Operating System* 

7« The Operating System should keep track whether an End of 
Fije has occurred and return an error code if a subsequent 
READ NEXT is executed prior to the execution of a CLOSE 
followed by an OPEN statement» or the execution of a START or 
READ with KEY statement for relative and indexed files. 

8. Nonpermanent files should be qualified by the Job nafae in 
order to make them unique in case of multiple executions of 

the same program. 

9» Four file OPEN statements must be supportedl OPEN INPUTt 

OPEN OUTPUT, OPEN I/O, and OPEN EXTEND. The first three are 

self-explanatory. OPEN EXTEND opens the file in output mode, 

but positions the file so that the last rec3rd is now the 
preceding record. 

10. Three CLOSE statements must be supportedx CLOSE FILE, CLOSE 
. REEL, and CLOSE UNIT. CLOSE FILE terminates processing on 

a file. CLOSE REEL and CLOSE UNIT terminate processing on 
the current volume and prepare the next volume of the same 
file ,for processing. CLOSE REEL/UNIT only apply to 
sequential files in the output mode. 

11. An input file may be dec fared as opt iona I • This means that 
the file may or may not be present when opened. If it is 
not present, then the first subsequent READ statement will 
give the "At End" condition. 

12 • Tape files may be labelled or unlabel led. Record formats 
F, V, Df U, and S must be supported on tapes, the blocking 
mechanisms defined in the label standards must be supported 
on tapes, and multl reel files and mul ti file reels must be 
supported. String consideration should also be given to 
support of IBM tape label conventions. 

13» When the new label standard is defined in JOD COBOL, strong 
consideration should be given to including It in IPL 
COBOL. ASL should ensure that this situation is reviewed 
periodically to see if ay new requirements on the I/O 
system emerge. 

1^. Emerging Requirements 

COOASYL current ly has a task group (the File Processing 

Task Group) at work clarifying and extending the I/O 

facilities of JOD COBOL. ASL should periodically review 

the progress of the FPTG work to determine whether any of 
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their proposals should be incorporated in IPL COBOL and 
what additional requirements such inclusion might impose on 
the IPL I/O system. 



1. Code conversion does not affect the placement of records for 
indexed sequential files. 

2. Provision must be made for the use of a program specified 
I/O error routine to be called after completing the standard 
I/O error routine or upon recognition of an invalid key or 
end of file condition when an INVALID KEY pnrase or AT END 
phrase respectively has nPt been specified in the I/O 
statement. 

3» Four types of record I/O statements must be supported! 
WRITE, READ, REWRITE, and DELETE. Each may be keyed or 
unkeyed. WRITE, READ, and DELETE are self-explanatory. 
REWRITE replaces an existing record. REWRITE and DELETE 
operate on the last record read, in a sequential 
organization. 

km A START statement exists in COBOL? its function is basically 
internal and consists of positioning a file by providing a 
new key value. Support of this statement by the O.S. (by 
initiating a SEEK operation) could enhance throughput. 
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5. The to I lowing chart summarizes the valid ODeratlons for a 
file in output mode. 



Access 



Organization 



WRITE 

(NO KEY) 



WRITE 
(KEY) 



SEQUENTIAL 



RANDOM 



DYNAMIC 



I I 

SEQ I REL I 
I I 



INDX 



I REL 

\ 



INOX I 
I 



REL 



I INDX 
I 



.-- — + — - 4.-™ — ♦ — —+-. — —«4.-—- — ^-— . 

D I I I I I 

I t : 11 I 

YES I YES I YES I NO I NO I NO I NO 
I I t t I I 



NO 



I 

\ 

I NO 

I 



NO 



I I 

I I 

J YES I 

I i 



YES 



YES^ 



I 
I 

I YES* 
. I 



Buffering may bd advantageoust since WRITE statements may 
be primarily in ascending order* 
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6. The following chart summarizes the valid operations for a 
file in input modex 



Access 



Organization 



START 



READ 

(NO KEY) 



READ 
(KEY) 



SEQUENTIAL 



.- +— 4^ — -. 

I I 

SEQ I REL I INOX 
I I 



+ + 

\ I 

NO P YES I YES 

I I 



i 1 

I I 

YES I YES I YES 
1 I 



NO 



{ I 

i I 

I NO I NO 

i I 



I 

RANDOM I DYNAMIC 
I 

♦ 1 4. , 

I I I 

REL I INOX I REL I INDX 

I I I 



+ 

I 
NO I NO 

I 



I YES 

I 



-4- 

I 

I YES 

I 



t \ I 

I I \ 

NO I NO r YES* I YES* 

I 1 I 



I 

I 

YES I YES 

I 



♦ Buffering may be advantageous 



1 1 

t t 

I YES ♦ I YES* 

I I 

.4.......4....... 
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7. 



The following chart summarizes the val id operations for a 
file in update modeo 



I Access \ SEQUENTIAL I RANDOM I DYNAMICI 

I I- f +— .• — J™- — 4. — .— I ♦ I 

I Organization I SEQ I REL 'l INDX JREL IINDX IRELIINDXI 

4..... — +. 4- +— — — 4 — -- — + — 4.™4. — --4. 

4..... «- 4. .«.4.«....4. 4. - — 4. 4. -4.- 4. 

I START 1 NO I YES I YES I NO I NO I YES I YES I 

«•----- -----•«. — - — 4.---— 4.™— -f — ----4- — »f -4- --♦ 

1 READ ill I I I I I 

I (NO KEY> I YES I YES I YES INO I NO lYESIYES I 

4.- . --4. * - — 4^ + •••: «■ ♦ + 

I READ I II I I I I I 

1 CKEYED) I NO I NO I NO lYES lYES lYESIYES I 
4. ...4.— -•.4.. — .4.. ..4...... .4. 4-*— f -I- 

I REWRITE II I I I II I 

I (NO KEY) I YES*I YES I YES INO INO INO INO I 

4. — ..f... — 4 — ...4.. — - — 4.-. — ...4.. .— 4.- — 4... ..4. 

I REWRITE III 11 I II 

I (KEYED) I NO I NO I NO IYES»» IYES»* lYESIYES I 

4. — --. — ..•••4......4......4.......f --;!•• — ♦ — '■¥ -4- 

I DELETE III I I I I I 

I (NO KEY) I NO I YES I YES INO INO INO INO I 

4.-. ..4......4.....-4.... 4.......4. ..4.-.- 4.. ...4. 

I DELETE I II I I II I 
I (KEYED) I NO I NO I NO IYES»» IYES»» lYESIYES I 

4. .••.•4. ...4.— ...4.......f....«-4..*....4. — .^ -4- 

I WRITE III II I I I 

I (NO KEY) I NO I NO I NO INO INO INO INO I 

4...-. ....^ ♦ ♦— --4. — --. 4........4 f« -4. 

I WRITE I lit I III 

I (KEYED) I NO I NO I NO t YES»*»I YES»»»I Yes I YES I 

4.— . «« — -4. — .•.4. — --.4.™.--4.-— — -4-— — — 4.™ 4. — -•4. 

♦ Record size cannot be changed 

»* Must refer to an existing record 

♦♦♦ Must not refer to an existing record 



Each file in a program may have associated with it a FILE 
STATUS data item. This two character item is updated with a 
status value during each executed reference to the file* It 
must be possible to uniquely identify these conditions from 
the status responses of the I/O system. 



M SUCCESSFUL COMPLETION 
The usual case* 
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02 SUCCESSFUL Read of a record with a DUPLICATED KEY value. 

For an INDEXED file, a READ NEXT operatiori, based on an 
Alternate Key for which Duplicates are Allowedt has retrieved 
a record which has the same "Key of reference" value as that 
of the next record. 



iJL AT END (end of f i I e conditi on) (Sequential Access) 

A READ NEXT operation (Sequential or Dynamic Access) was 
unsuccessful? there are no more records available in the 
file. 



2i INVALID KEY - OUT OF SEQUENCE 

. A WRITE to an INDEXED file in SEQUENTIAL OUTPUT mode 
attempted to create a record with a Prime Key value which 
was not greater than the previous record written. 
•. A REWRITE to an INDEXED file in SEQUENTIAL I-O mode did not 
specify the same Prime Key value as the preceding READ. 

2il INVALID KEY - DUPLICATE KEY VALUE 

. A WRITE or REWRITE to an INDEXED file would have created 2 
records with the same key value in the Prime index^ or Ih 
one of the Alternate indexes which does not allow 
dupl icates. 

. A WRITE to a RELATIVE file addressed a relative record 
position which was already occupied. 

25. INVALID KEY - NO RECORD FOUND 

. A START operation did not find a record which satisfied the 

logical key condition expression. 
. A format 2 READ operation (non-sequential access to a 

RELATIVE or INDEXED file) did not find a record with the 

key value specified. 
. A REWRITE or DELETE statement to a Relative or Indexed file 

in non-sequential (Random or Dynamic) access mode did not 

find a record with the key value specified. 

Zk INVALID KEY - BOUNDARY OVERRUN 

A WRITE statement to any file on a mass storage medium has 
addressed a location which is beyond the externally 
specified boundary of the file. 
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M PERMANENT ERROR 

A permanent error may occur at any time that the system 
attempts a physical I/O operation which results in an 
unrecoverable error (including OPEN, START (INDEXED fileslt 
CLOSE UNIT, and CLOSE, as well as READ, RE/iRITE, WRITE or 
DELETE). 

None 



ADVANCED SYSTEM LABORATORY 

IPLOS GDS - INTERNAL IPLOS REQUIREMENTS 



APOXE 



17 
75/06/11 



SLfi-aciye£S 



None 



6.1.3.2.5 REQUIREMENTS ON PROGRAM MANAGEMENT 
None 

6.1.3.2.6 REQUIREMENTS ON STORAGE MANAGEMENT 
None 

6.1.3.2.7 REQUIREMENTS ON SYSTEM MANAGEMENT 

The following definitions, used by the COBOL design team^ are 
necessary in order to lend absolute clarity to the intent of 
requirements stated in this sectionl 

••Binding" is the combination of 2 or more object modules into 
one single object module, requiring offset adjustment and 
possibly a change in the OP code. 

"Linking" is the resolution of external references from one 
module (either the result of a compilation or of a binding 
process) to another. It can be done either statically or 
dynamically at the time of the call or reference. 



"Loading" is what the name impliesi the loading of 
in the computer memory for execution. 



a program 



1. Since the COBOL compiler will initialize a ,1. 1, data entries 
declared in the WORKING-STORAGE SECTION, the loader should 
be capable of zero or space filling large areas. In 
addition, it should allow initialization of individual data 
items (VALUE clause). 

2. The COBOL compiler requires a linking facility both in 
static and dynamic modes. There is no requirement for a 
binding facility. An efficient Linking Loader is all that 
is required . 
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3. All external references should be qualified by the name of 
the module where they are declared. 

^. Unresolved references should not cause more than a warning 

message at linking time. At execution time, they should 

cause a trap to the Linking Loader to attempt to resolve 
them. 

6.1.3.2.8 REQUIREMENTS ON 0C5 

None 

■&T.l f? ^i„£QRTRAN 

6.1.3.3.1 GENERAL REQUIREMENTS 

1. A means for determining the current CPU time* time of day» 
and date must be provided. 

2. If a digit, or a character, string follows the STOP or PAUSE 
statement this string must be displayed and must be 
availaole for examination. 

3. Facilities which permit an executing program to display 
information in the dayfile and/or on a terminal are required 
for the DISPLA and REMARK sub-routines. 

k» A program must be able to distinguish between batch and 
terminal usage. 

5. The first piece of software to detect a condition which 
caused or will cause an error must flag the error. 

6.1.3.3.2 REQUIREMENTS ON SCL 

1. It is necessary for a programmer to be able to examine the 
digit, or character, string, which may accompany a FORTRAN 
STOP or PAUSE statement, with SCL commands. 

6.1.3.3.3 REQUIREMENTS ON JOB MANAGEMENT 
None . 

6.1.3.3.ff REQUIREMENTS ON DATA MANAGEMENT 

1. Security. A program must be able to establish its right to 
access a file. For example it may be able to write on a 
file when that file is not associated with another program. 

2. IPL FORTRAN provides five File and Record Maoipulation 
Statements. These are: REWIND, BACKSPACE, ENDFILE, 



NCR/CDC PRIVATE REV 06/13/75 



NCR/CDC PRIVATE REV 06/13/75 



ADVANCED SYSTEM LABORATORY 
IPLOS GOS - INTERNAL IPLOS REQUIREMENTS 
BACKFILE, and SKIPFILE. 



APDXE 



18 
75/06/11 



ADVANCED SYSTEM LABORATORY 

IPLOS GOS - INTERNAL IPLOS REQUIREMENTS 



APDXE 



19 
75/06/11 



5. 



He suggest that a partitioned file structure should be used 
to facilitate the implementation of these statements. 
Partitions within the file can be named and/or numbered. 
Each partition is separated from its predecessor by an 
end-of-parti tion marker which is part of the preceding 
record. The last partition in the file need not be 
terminated by an end-o f-par ti tion. The file is terminated 
by an end-of -inf ormat ion marker. 

The implementation of a partitioned file scheme should 
result in maximum flexibility. For example it should be 
possible to expand a given partition. From the FORTRAN 
point of view it is not necessary for the partitions to be 
contiguous on a physical device* so long as the logical 
structure appears contiguous. 

REWIND positions the current partition at the beginning of. 
its first record* but has no effect if the partition is at 
its initial point. ASL/C insist that this statement causes 
the first record ever written in the sequence of files to 
become the next record. It is not clear that this is the 
intention of IPL FORTRAN. This position must be clarified. 

BACKSPACE positions the file at the beginning of the 
preceding record. If there is no preceding record BACKSPACE 
has no effect. This is easily Implemented for U and F file 
organizations and is difficult for all other sequential file 
organizations. However, the most flexible sequential file 
organization is the Y type and this will be the IPL FORTRAN 
default for sequential files. IPL FORTRAN insists that 
BACKSPACE be available for records in a Y organized file. 

NOTE! An endfile record Is counted as a record during 
execution ot a BACKSPACE statement. 

An ENOFILE statement causes an end-of-partltlon marker to be 
written and this may be considered as the FORTRAN endfile 
Record. 

IPLOS point out that any form of data delimiter involved in 
the implementation of ENDFILE Is likely to cause 
Incompatibility with other language processors. 

Execution of a BACKFILE statement positions the. file at the 
start of the preceding partition. If there Is no preceding 
partition the statement has no effect. 

SKIPFILE will position the file at the beginning of the next 
partition. If a file Is positioned at the end of the last 
partition SKIPFILE will cause an error to be generated. 
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8. BACKFILE and SKIPFILE are applicable to sequences of 
sequential files. It is not clear whether or. not files in a 
sequence can be updated* and/or extended. The general 
consensus of opinion is that the sequence of sequential 
files usurps the functloi of the operating system. 

IPLOS will insist that ENDFILE* BACKFILE, and. SKIPFILE are 
restricted to Magnetic Tape files*. It is not clear that 
this approach satisfies ANSI standards. 

A clearer definition of the requirements for these features 
must be generated. 

9. Both the UNIT function and the EOF function need to be able 
to detect an end-of-inf ormatl on marker. 

10. The EOF function must be able to detect an end-of-partition 

marker. 

11. The UNIT function must be able to check for parity errors 
on a specified device. 

12. The function lOCHEC issues a parity check request against a 
file and pot a device. It Is understood that if the file 
connected to the specified unit is a mass storage file ^ny 
error In the device on whicn the fi I e resides will be taken 
as a parity error. A single mass storage file Is not 
necessarily mapped into a single mass storage device, and 
the device may hold more than one file. 

13. The function LENGTH must return the number of bytes in the 
last physical record read by BUFFER IN. This I/O request 
may have requested more or less bytes than the physical 
record contained. LENGTH enables the user to determine if 
the buffer length is correct. 

With the LENGTH function lost data can be Indicated but It 
Is understood that It is absolutely impossible tor IPLOS to 
say how much was lost. 

1^. The SHL I/O facilities were studied and were found to be 
not sufficiently comprehensive to allow us to Implement 
FORTRAN I/O using SWL I/O. It would not be desirable to do 
so in any case because it moves the FORTRAN program at 
least one stage farther away from the OS and hence the 
external environment. 

The Data Manager will be available as part of IPLOS on the 
simulator. SWL would like some of the I/O requests to be 
directly available as part of the simulator* thereby 
avoiding IPLOS. At the moment IPL FORTRAN would prefer a 
single Interface with the hardware? this Interface wll I be 
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15. 

16* 
17. 
18. 

19. 

20. 
21. 



Sensible default values are required for the Data 
Management macros where these are not currently supplied. 
These may be installation dependent. 



A clear definition is needed of what happens when a 
Management I/O request cannot be satisfied. 



Data 



Choice of suspension or continued execution of a program 
after issuing an I/O request is required. 

Whilst requiring specific features in IPLOS to support 
FORTRAN I/O, it is desirable that files compatible with 
other language processors can be produced by FORTRAN 
programs. 

The IPL FORTRAN ERS will contain a matrix which defines the 
permissible combination of IPL FORTRAN I/O statements with 
file organizations and record structures. This will help 
to clarify the FORTRAN requirements on the O.S. 

Formatted records are assumed by the O.S. to contain ASCII 
characters, and conversion utilities may be required. 

It is not clear whether an attempt to write on a unit which 
is not connected to a file should cause an error or not. 
FORTRAN could undertaKe to connect a scratch file during 
execution of the first write on the specified unit. The 
requirements here must be defined. 

6tlt?f?T/tjLl Sg^jjJjeja enfs o n Volun^ e Management 

None 

6«Xf?t3.^,2 — Requirements on File Mangqf>n!?nt 

1. There is a need for a specific means of associating a 
FORTRAN unit number with a file name and for associating 
files with a program. In IPLOS terminology, this means 
FORTRAN unit numbers must be associated with files and unit 
numbers must be associated with Jobs. A program must be 
able to determine which files have been associated with it. 

A method of resolving this requirement is suggestedi 

The LFN should have standard form. The suggest ion is that 
the LFN is FTN#<N>, where <N> is the FORTRAN unit number. 
For example, the FORTRAN statement OPEN(10» would generate 
FTN^IO for the LFN. 

The association between a FORTRAN unit number and a file 

NCR/CDC PRIVATE REV 06/13/75 



1 
2 

3 

<♦ 
5 
6 
7 
8 
9 
10 
11 
12 
13 
1^ 
15 
16 
17 
18 
19 
20 
21 
22 
23 
Zk 
25 
26 
27 
28 
29 
30 
31 
32 
33 
3if 
35 
36 
37 
38 
39 
^0 
t»l 
'♦2 
kZ 

if5 
^6 
t»7 
^8 
^9 
50 
51 
52 



ADVANCED SYSTEM LABORATORY 

IPLOS GOS - INTERNAL IPLOS REQUIREMENTS 



APDXE 



21 
75/06/11 



l4. 



outside a program can be achieved by Job control consisting 
of a sequence of SCL commands. For example! 

DCL FTN<?10,TYPE = FILE 
FTNfflO.FN = -ALPHA* 
ATTACH FTN^IO 
FTN 

One important aspect of FORTRAN I/O is that in general no 
file organization or specific devices . are implied. For 
example, a p rogram cannot specify that a unit number refers 
to a magnetic tape. The exception is BUFFER I/O. 

In order that we may implement sequences of files, IPLOS 
must provide a partitionad file capability wnere a logical 
file (composed of FORTRAN logical records! corresponds to a 
partition in the file. Each partition should be accessible 
by name and/or number as a separate entity within the OS. 

Information regarding file existence must be available to 

the program. 



A file may exist but not be associated in any way 
program. 



with the 



The FORTRAN definition of "file existence" requires 
clarification. At the moment FORTRAN defines existence with 
respect to a program. For example, if a FORTRAN unit is 
CLOSED with STATUS = 'DELETE*, the file connected to that 
unit no longer exists for that program. The user is then at 
liberty to try to create another file with the same name. 
The problem is that we are not convinced that the first file 
should be deleted from the permanent file catalogue if it is 
a permanent file. 

If the file is not connected to the program requiring the 
information, we must Know if it is connected to another 
program, and in what mode. 

INQUIRE by file name is not possible at the moment. IPLOS 
must support this feature. 

Permanent files arfi known by their "Real IDs"? their names 
in the permanent file catalogue. FORTRAN may have to keep a 
table of LFNs and corresponding Real IDs in order to support 
the INQUIRE statement. 

FORTRAN does not have to specify a file name and OS requires 
files to be named, so programs must be able to determine 
system supplied names. For example, a FORTRAN CLOSE 
statement can make a scratch file permanent. The {lie name 
is an optional parameter on the FORTRAN OPEN statement so 
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10. 



11. 



12. 



13. 



1^. 



that a FORTRAN program could create a permanent file to 

which it did not give a name. FORTRAN provides no 

facilities for the user to identify such a file once the 
unit to which it w^s connected is closed. 

When a FORTRAN OPEN "statement does not specify a STATUS 
parameter* the OS should supply a default which can be made 
Known to the program. 



Programs must be able 
Sequential Access files. 



to distinguish between Direct and 



If a direct access file was created with the Maximum Record 
Number property then the maximum number of records that the 
file can contain is fixed. The maximum length of each 
record is also fixed but shorter length recods can be 
-employed so that the product of the maximum record number 
and current record length does not indicate the length of 
the file. 

An executing program must have the ability to create a file 
if it does not exist. However* the program cannot supply 
information about devices and file organizations (other 
than sequential or direct) and the GOS does not define 
default values. It is not possible for IPL FORTRAN library 
I/O routines to specify the vsn* efnq* gen* ver, or expd 
parameters of the FILEID macro. 

Whilst the file creation process is in progress .the file 
organization may be U type* at the end of the process the 
user may wish to change the description of the file 
organization. Therefore* the ability to redefine the 
description of a file's organization at runtime is needed. 
This is not presently possible* as f i le organizat ion* as 
well as access method* is fixed at the time the file is 
created. 

The default file organizat i on f or BUFFER I/O will be the 
sequential U type file organization. 



&tlf?t?T^t? Requirem ents on Record Management 

1. Definitionst 

The basic repository of data in IPL FORTRAN I/O is the 
logical record and unquai ifed use of record in the following 
sections means logical record. The IPLOS definition of 
logical record is acceptable to IPL FORTRAN. The four kinds 
of FORTRAN record are« 

formatted - (ASCII) 

unformatted - (binary, Variable length) 

f ree-f ield, and 
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endfile 

The endfile is a record without a length property. 

A free-field record is essentially a record of unknown 
• length: unknown* that is* until it is complete. Each 
free-field I/O request causes the transmission of part of 
the record. 



2. 



3. 



7. 



FORTRAN only allows certain combinations of record types and 
a record must be marked as either formatted (character) or 
unformatted (binary). 

Record lengths should be in bytes. 

The last record of a file need not be an endfile record. 
This implies that the OS must provide some sort ot file 
termination mark to terminate files and which is 
distinguishable from a FORTRAN endfile record. 

IPLOS should flag ^n error if an attempt is made (on a 
direct access file) to read a record which has not been 
written. 

Implementation of free field I/O will involve the use of 
discrete records for every free-field write. The FORTRAN 
library routines will unpack free-field records on input and 
only issue an input request when the last record r<ead is" 
exhausted. Thus every free-field write will cause an output 
request to be issued to the operating system, whereas a 
free-field read will not necessarily cause an input 
request. 

The record length of a free- field record is not known until 
it is complete and we would hope that the entire contents of 
an incomplete free-field record would not be lost if a 
program terminated abnormally and the file was still open. 



6.1.3. 3 



ju lrements on Block Manag e ment 



1. Buffer I/O represents a strict byte by byte transfer of 
data. No structure can be imposed on the records or file by 
the OS.. The Sequential U file organization suggests itself 
in this case. However* BUFFER I/O can transmit records of 
varying lengths and it is not clear whether or not the 
records in a U organized file can be of varying lengths. 

2. BUFFER I/O and block level access should ba synonymous. At 
the moment data transfers can only occur in single blocks 
and unused space in a Plock is wasted. 

3. BUFFER I/O may be incompatible with a paged environment. 
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With BUFFER I/O execution continues whilst the I/O request 
is being satisfied and the user must ascertain when it is 
complete^ For a variety of reasons the Operating System may 
not choose to allow the program to continue until the 
request is satisfied. If IPL FORTRAN intends to provide 
BUFFER I/O then the FORTRAN ERS should make it clear that 

control may Qiil necess ari \ v be returned to the program 

before the I/O request is complete. 

ay.i£:ei!ignts.9Q,Dg.vUa Qy^ivars 



6.1.3.3.5 REQUIREMENTS ON PROGRAM MANAGEMENT 
None 

6.1.3.3.6 REQUIREMENTS ON STORAGE MANAGEMENT, 
None 

6.1.3.3.7 REQUIREMENTS ON SYSTEM MANAGEMENT 
None 

6. 1.3. 3. 8 REQUIREMENTS ON DCS 
None 

IRQ 



6.1.3.<f.l GENERAL REQUIREMENTS 



1. Definitions 



In this document we distinguish between 'mandatory 
services', 'desirable services', and 'exploitable 
services'. 



Mandatory services are considered 
requirements for effective RPG support. 



the 



minimal 



BjgSl!:al2lS S^ri^ic^s nill ease program conversion and 

encourage migration. 

Exp loita ble services are not required by RPG but will be 
externalized to the IPL RPG user. 



Z* Telecommunications 



1 
2 
3 

5 

6 
7 
8 
9 
10 
11 
12 
13 
1^ 
15 
16 
17 
18 
19 
20 
21 
22 
23 
2^ 
25 
26 
27 
28 
29 
30 
31 
32 
33 
3^ 
35 
36 
37 
38 
39 
AO 
^1 
t*Z 

^5 
^6 
t*7 
<fd 
h9 
50 
51 
52 



ADVANCED SYSTEM LABORATORY 

IPLOS GDS - INTERNAL IPLOS REQUIREMENTS 



APDXE 



25 
75/06/11 



IPL RPG will have a telecommunications capability* I would 
like to defer a detailed analysis of requirements until I 
have studied the 'standard terminal definition'. 

6.1.3.^.2 REQUIREMENTS ON SCL 

None . 

6.1.3. «♦. 3 REQUIREMENTS ON JOB MANAGEMENT 

None 
6.1.3.'*.^ REQUIREMENTS ON DATA MANAGEMENT 

1. RPG requires the following mandatory interface? 

RPG allows the programmer to specify his own procedure for 
I/O error conditions. Data management must look for such an 
error procedure on I/O error conditions. 

2. An RPG implementation on IPL will only be effective if the 
compiler can accept EBCDIC files containing fields with any 
of the data types defined by the RPG de facto standard. 

To accomplish this* the following services are de sirable ! 

An intercept provided such that all records read from a tape 
may be translated under control of the RPG program. ^ This" 
includes all label records. 

A link back to the data uanagement routine after labels have 
been translated such that the labels are checked by the 
system label checking procedures. 

An 'on the fly' utility provided that will accomplish 
translation of a record only after the RPG program has 
recognized its data type composition. 

6.1,.3. V»tt, 1 ReouireTients on Volume Mana g ement 

None 

^.1.3.^.^.2 Requirements on File Management 

1. Support of the following file structures is m andatory t 

Sequential F file structure (SF) 

Sequential D file structure (SO) 

Sequential S file structure (SS) 

Relative fixed length structure (RF) 

Indexed File Organization (IS) 
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2» Support of the following interfaces is mandatory t 

RPG allows the programmer to specify his own procedure for 
processing labels whether they be non-standard or ANSI 
standard user labels* Data management is required to allow 
the specification of two label processing procedures. One 
procedure for non-standard labels or ANSI UHL's» the other 
for ANSI UTL"S. 

3. Support of the following file structures is dfiSiCflMfi* 

Sequential U file structure (SU) 

Foreign file organization 

NCR variable length structure (2 byte VLI) 

'f. Support of the following feature is desirable t 

De facto standard RPG allows label procedures to be 
specified on mass storage devices irrespective of file. 
organization. 

5. Support of the following file structures is exploitable : 

Sequential Y file structure tSY) 

Relative variable length structure <RV) 

User defined file organization 



6. 



The 'alternate* key feature of Indexed files is 
BUJixSialSLLl though it is exoloitab le . ^ 



D5l 



1. Support of the following record requests is manda tor y I 



REQUEST 
GET 

GETKEY 
PUT 

PUTKEY 
REPLACE 
DELETE 
OELKEY 
FINDKEY 
FINDD 



USAGE FILE ORGANIZATION 

1,10 SF,SO,SS,IS,RF 

ItIO SF (see note), IS, RF 

0,IO,E SF,SD,SS,IS,RF 

0,10 IS,RF 

10 SF,S0,SS,IS,RF 

10 IS,RF 

10 IS,RF 

1,0,10 IS,RF 

1,0,10 SF,S0,SS,IS,RF 



NOTEX 



A sequentially organized mass storage file, that has 
fixed length file structure, may have its records 
randomly accessed by relative record number in an RPG 
program. 

RPG has the following J^D^alsny requirements on record 
address valuess 
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a) Record addresses are relative to the start address of a 
file (and would be valid for a copy of the file). 

b) Record addressds are valid for the life of a file as 
long as the user does not update the file in such a way 
that record positions are altered. This means that data 
management must not reorganize records wi.thout the users 
acknowledgement. 

c) Record addresses can be used to access records in any 
type of file organization. 

3. Support of the following record requests is desirab I gi 



REQUEST 


USAGE 


FILE ORGANIZATION 


GET 


1,10 


SU 


PUT 


0,10, E 


SU 


REPLACE 


10 


SU 


FINDD 


1,0,10 


SU 



k. Support of the following interface is desirable: 

De facto standard RPG allows signed packed as well as 
alphanumeric keys for indexed sequential files. He request 
that keys be communicated to the access method through the 
use of parameters giving address, length in bytes, and data 
type. 

5. Support of the following record requests is explo ita bf^t 



REQUEST 


USAGE 


FILE ORGANIZATION 


GET 


1,10 


SY,RV 


GETKEY 


1,10 


RV 


PUT 


0,10, E 


SY,RV 


PUTKEY 


0,10 


RV 


REPLACE 


10 


SY,RV 


REPKEY 


0(see note)tIO 


IS,RF,RV 


DELETE 


10 


RV 


DELKEY 


10 


RV 


FINDKEY 


1,0,10 


RV 


FINDD 


1,-0,10 


SY,RV 



NOTEI RPG allows records to be added to an existing file 
which has output usage and indexed or relative file 
organization. Such addition of records is subject to 
a 'duplicate record' situation, i.e., his request to 
•overwrite' the existing record would be serviced by 
REPKEY. 
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6. 1*3> ^#A>U Requiremen t? on Block Management 

!• Support of the fol lowing feature is des irabJe t 

Oe facto standard RPG allows indexed file keys to be 
contained within a block prefix when the records are not 
blocked. 



.3. 

None 

6.1. 3#^. 5 REQUIREMENTS ON PROGRAM MANAGEMENT 

1. It is a high priority objective of the RPG project that the 
RPG user need never see a 'hex* dump. 

Support of the following interfaces is therefore mandatorv t 

A hook provided between the OS program error routine and 
RPG's symbolic dump formatter. 

An interlace provided whereby the RPG symbolic dump 
formatter may read the core image RPG program (that is in 
error) before the jlob is terminated. This interface should 
be generalized so that it is available to a "dynamic" 
symbolic dump which, returns control of an executing 
program. 

6.1.3.^.6 REQUIREMENTS ON STORAGE MANAGEMENT 

None 
6.1.3.^.7 REQUIREMENTS ON SYSTEM MANAGEMENT 

None 
6.1.3. ^.8 REQUIREMENTS ON DCS 

None 
6tJlt?«g. ELZI 

Requirements to be supplied 
Requirements to be supplied 
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^Ui.5i.7_APL 

Requirements to be supplied 

6.1.3.8.1 GENERAL REQUIREMENTS 
None 

6.1.3.8.2 REQUIREMENTS ON SCL 
None 

6.1.3.8.3 REQUIREMENTS ON JOB MANAGEMENT 
None 

6.1.3.8.^ REQUIREMENTS ON DATA MANAGEMENT 

None 
.feiljLi • fijJijtl S^flylC^mjSPTS OP Volung Mgng^ ^m^nt 

None 

■&«..Jl«3,r&aL!t».£.^£fiayl!:£i35niS,fi.Q..E.LI.S..Mana5gI!lJ£Jlt 

1. A fast open function is needed for scratch/temporary files* 

2. The capabi I ity to switch processing states on files must 
exist in the form of a RE-OPEN function (i.e. 9 write a 
temporary file and then in the same program be able to read 
the file). 

3. Because the SORT will be working in a shared media 
environment a requirement exists to uniquely identify the 
temporary work files associated with each sorting function. 

6.1.3.8.^*3 Requirements on Record Management 

None 

None 
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&tJ.T3yg«>«3 Requ ir emen ts on Device Driv ers 

1« Certain SORT techniques require the use of read backward 
tape. If the hardware is provided the device drivers need 
to provide the read backward function. 

6.1.3.6.5 REQUIREMENTS ON PROGRAM MANAGEMENT 
None 

6.1.3.8.6 REQUIREMENTS ON STORAGE MANAGMENT 
None 

6.1.3.8.7 REQUIREMENTS ON SYSTEM MANAGEMENT 

1. There exists a need to dynamical ly I inK/bInd modules at run 
time. . ' 

2. The need also exists to be able to linK/edit modules prior 
to execution/run time. 

6.1.3.8.8 REQUIREMENTS ON OCS 
None V 

3MS 

6.1.3.9.1 GENERAL REQUIREMENTS 

1. An explanation is required in the IPLOS Structure Overview 
of how the OS intends tapes to be used. 

2. In the IPLOS some means of associating files into processing 
groups must exist (i.e., associating one or more user files 
to a common log file). The Data Recovery utility must have 
a means whereby it can ascertain the identity of the user in 
order to properly tracK the usage of monito-^ed files. 

6.1.3.9.2 REQUIREMENTS ON SCL 
None 

6.1.3.9.3 REQUIREMENTS ON JOB MANAGEMENT 

1. Although the logging utility will not monitor entire 
Checkpoint files it must be able to uniquely identify the 
Checkpoint in order to properly recover data files to a 
predetermined point in time. 

2. The Checkpoint function must call the Logging utility at the 
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beginning of each Checkpoint that is requested* if the owner 
of the file has Indicated that tracking of Checkpoints is 
required. 

3. Control on user abort sufficient for us to flush buffers* 
• etc. 

6. 1.3. 9. if REQUIREMENTS ON DATA MANAGEMENT' 

1. Password checking for user and terminal ID's» and macros to 
retrieve the ID's. 

2. Ability to rename the record access method processing a file 
to be our own method. Our method must be able to use 
standard record requests and open additional files. 

3. Asynchronous I/O is required. 

>. Wait option with time limit on data management requests. 

5. ■ Data streams are required. 

6. Data streaming is required. 
^*^»?t9T^»t ..R^quiremaatS, On-V.oluma^Mgnggemgnt 

None 
&,«li.3,2.^.g , Reqi^jrenigntS 9n EU^.Mgngqem^nt. 

1. Rapid open-close sequences. 

2. Multiple concurrent independent opens in a run* task* etc. 



1. 



A method to relate our data description files with user 
files. 

Concurrent update (multiple writers) on all disk file 
organizations supported by Cobol. 

The Data Recovery utility must work in harmony with the File 
Manager. The Logging portion of the utility should be 
called by the File Manager whenever any file that is to be 
monitored is opened. 

The Logging utility will need to access the Request Block of 
the user file being opened. 

3.9. t»,3 i^eau lrements on Record Management 

Locking via record requests* including Finds* Ipcking by 
file address, and locking of all records on a file. 
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2. Option, on Find for obtaining a file address without record 
retrieval • 

3. Delete and Replace by file address and key so we can modify 
records in addition to the last one read. 

km Pointer, mode of Get» to allow inspection of the record 
without transfer into a separate record buffer. 

5.. Identical options for major and minor index keys for a 
multiple-index file (duplicates permi tted/restr ictedt key 
modification permi tted/restricted» etc.). 

6« The Logging utility must be attached in such a manner that 
all Record I/O requests for monitored files pass through the 
I ogging util ity • 



6.1.3. c 

None 
6.1.3.9.^ . 3 Reauiremeni 

None. 

6.1.3.9.5 . REQUIREMENTS ON PROGRAM MANAGEMENT 

1. Use of LNS by some modules is required. 

2. A simple way to determine at run time a routine's program 
name» the date/time of compilation* and the compiler version 
used. 

6.1.3.9.6 REQUIREMENTS ON STORAGE MANAGEMENT 

1. Secure libraries to restrict user substitution of our major 
routines at run time. 

2. Shared segments between runs» with serialization macros 
provided. 

6.1.3.9.7 REQUIREMENTS ON SYSTEM MANAGEMENT 
1. ' Dynamic link loading is required. 

2# Common requests for all terminal types. 

6.1.3.9.8 REQUIREMENTS ON DCS 
None 
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6.1.3.10 Media U til ities 

Requirements to be supplied 
&t 1. ^. U .^Sz^lfiin^UlliUUs 

Requirements to be supplied 
6.1.3. 12 lOSS 

6.1.3.12.1 GENERAL REQUIREMENTS 

1. Mutual Exclusion to Shared Resources by serializing user 
access is required t bearing in mind that some "users" are on 
the hardware/firmware side of the lOSS interface. 

6.1.3.12.2 REQUIREMENTS ON SCL 
None 

6.1.3.12.3 REQUIREMENTS ON JOB MANAGEMENT 
None 

6.1.3.12.^ REQUIREMENTS ON DATA MANAGEMENT 

1. A requirement for data streaming exists. It is a 
requirement that the operating system provide the necessary 
close-coupling of the user's buffer condition with calls 
upon the device interface software in order to implement the 
required level of data streaming. 

6.1.3.12.^.1 Re q uirements on Volu me Man a gement 

None 

6.1.3.^.2.^.2 Reauire'me nts on File Managemen t 

None 

6t lit 3x12 >.itA3 &afluli:itin&nts QD_Efi^!:d Hgnaggnignt 

None 
None 
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e»l>3t l2.> >5 Requireme nts on Device Dri vers 

None 

&• 1.3. 12. 5 REQUIREMENTS ON PROGRAM MANAGEMENT 

1. Event Creationt Posting and Wakeup services are required. 

6.1.3.12.6 REQUIREMENTS ON STORAGE MANAGEMENT 

1. Proolems must be solved in the OS design for relating the 
real memory address of tables to a similar virtual address. 

6.1.3.12.7 REQUIREMENTS ON SYSTEM MANAGEMENT 

1. At system Init ia lizat iont and potentially whenever a 
processor is restarted, the location of tables used on both 
sides of the hardware/control ware/so ftware interface must be 
established for ail users. 

2. The data structures of the interface must be Initialized. 
The operating system must establish initialization and 
restart procedures in a general sense* and must include 
provisions for the lOSS tables and data structures. 

3. Visibility to the mechanisms and capabi I ities for generating 
a system from misce I laneous modules is required. 

6.1.3.12.8 REQUIREMENTS ON DCS 

1. The operating system must provide a path by which the 
system operator can communicate with the device interface 
software on problems of mutual concern. 



6.1.3.13 MSS 



6.1.3.13.1 GENERAL REQUIREMENTS 

1. The system (hardware and OS) must be designed so that the 
system down MTBF is a minimum of 168 hours of system power 
on time. 

2. The IPLOS must be designed to function with a minimum number 
of critical hardware elements. 

6.1.3.13.1.1 Er ror Det ection 

1. The general requirement is that IPLOS be capable of 
detecting all of the fault types which are. inherent to a 
given system element. System elements which cannot cause 
traps/interrupts or otherwise signal a fault state must be 



1 
2 
3 

<f 
5 

6 
7 
8 
9 
10 
11 
12 
13 
l«f 
15 
16 
17 
18 
19 
20 
21 
22 
23 
Zk 
25 
26 
27 
28 
29 
30 
31 
32 
33 
3t» 
35 
36 
37 
38 
39 
t»0 
^1 
^2 
^3 

k5 
^6 
M7 
<t8 
'f9 
50 
51 
52 



35 

ADVANCED SYSTEM LABORATORY APDXE 

75/06/11 
IPLOS GDS - INTERNAL IPLOS REQUIREMENTS ' 

periodically polled. 

2. Software timeouts must be provided for all channel 
communication (if not provided by hardware!. 

3. • Software timeouts must be provided for processor activity in 

a multiprocessor environment. 

if. Hardware status registers must be periodically examined for 
fault status (if no special signal is generated by one or 
more classes of faults). 

5. Errors in system elements which are not "directly 
interfaced" to IPLOS must be reported bacK and detected by 
IPLOS via standard system protocol. 

6. Recoverable system errors (hardware and OS) should be 
invisible to the customer. 

7. IPL Errors detected by IPLOS must included 

7.1 Memory 

Single error detected 
Uncorrectable error 

7.2 Processor 

Processor mal function condition bit set and processor 

fault status register value 

Processor hun^ (timeout in multiprocessor systemi 

7.3 Data/address paths 
Parity 

7.^ Peripherals 

Controller malfunction including timeout 
Device malfunction 
Media mal function 

7.5 Networks 

Node* Llne» Device* Media 

7.6 Other 

Power failure Imminent 
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1. The requirement here Is that IPLOS upon detection of a fault 
immediately attempt to assess the damage caused by the 
fault. 



2. 

3. 



Damage assessment must differentiate between critical errors 
,and noncritical errors. 

IPLOS equipment/conf iguration/allocation/assignment tables 
describing IPL hardware elements must be designed to allow 
damage assessment to efficiently pinpoint impacted 
processes/tasks/ Jobs. 



IPLOS damage 
interruptabi e. 



assessment 



must 



not 



be external ly 



tS£.)L 



1. Error recovery procedures defined and approved for the IPL 

must be implemented. 

2t Recovery action Involving unrecoverable errors In 
noncritical elements will not result in system shutdown. 

3. OS automatic recovery procedures must be provldedt such as 
data transfer retry on parity error, retry on timeoutst 
reconfiguration when a solid fault is detected, etc. 

'f. Recovery action in^^olving unrecoverable errors in critical 
system elements will be to attempt to initiate a system 
recovery. 

5. Jobs utilizing noncritical system elements which have 
unrecoverable errors must be temporarily suspended, 
restarted, or rerun, but, in any case, not allowed further 
access to the element until repair is effected. 

6« Error conditions should be recoverable after a repair has 
been made without having to rerun the entire Job. 

7. System restart must be capable of being liitiated without 
operator intervention. 



6.^.3. 1 



>conf JQu rat l QQ 



!• The OS must provide capabilities for system degradation and 
reconfiguration so that there are a minimum number of system 
critical elements. 

2. System reconfiguration capabilities must exist so that 
equipment can be worked on concurrently with customer 
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operaton (PM and remedial maintenance). 

3. Redundancy of al I units In the system should be supported by 
the OS for the customer that requres a high degree of 
availability. 

km Reconfiguration must include? 

^.1 Utilization of alternate paths to an element 

k»Z Logical deletion of a noncritical systeu element* 

^.3 Full access to logically deleted system elements for a 
maintenance task through standard system drivers, etc. 

k»k Reinstatement of . logically deleted system elements as 
well as addition of "new" elements 

kmS Logical deletion, maintenance access, and reinstatement 
of noncritical portions of system elements. 

5. Reconfiguration of critical system elements must be 
supported at system restart subject to the following 
considerations? 

5.1 The system will restart without the services of the 

element 

5.2 The system will operate without the services of the 

element 

5.3 The system restart process must be able to accept 
configuration parameters from an external source 

5\k The system must accept "new" elements introduced during 
system execution (elements which were configured out 
during restart) .. 

£jlJU5jl13a1j.5 CLflQguix&Qt R?iiaii: 

1. Diagnostic programmers must work with the OS programmers so 
that on-line diagnostic capability is built into the OS. 

2. The OS must provide clear Information and procedures to the 
customer's personnel when a nonrecoverabi e system fault Is 
detected. Where possible, the OS should automatically call 
In the necessary diagnostic. 

3. On-line diagnostic programs must operate concurrently with 
the customers operation, whether from a local or remote 
console. 
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*♦• Features must be provided for updating the maintenance 
software concurrent with customer operation. 

5# Area on mass storage devices must be reserved by the OS so 
that diagnostic tests can test the storage device using the 
reserved area. The 05 must provide protection from the 
diagnostics to the other areas of the storage device. 

.&tl.f..?.»,A.^t.lA^ S^m?tS.,.Ai:<:gS5 

1. Phone line couplers and related software must be provided 
which will provide the s^iiia maintenance testing capabilities 
to a remote C.E. as is provided to a local C.E. 

2. To satisfy some customer's security requirements* provision 
must be made so that the customer has control of when remote 
access to his system is allowed. 

6.1.3.13.2 REQUIREMENTS ON SCL 

1. Specific reconfiguration requests which can be issued by the 
MSS task will include the followingt 

1.1 Memory 

Assign page frames (contiguous real memory locations) 
or memory banks to MSS task. 

1.2 Processor 

Idle processor - this will effectively take an IPL 
processor "of f-l ine" and make it available exclusively 
for maintenance functions. 

Activate processor - Return processor to IPLOS 
activity. Assign a specific processor to a specific 
task. , 

1.3 Peripheral 

Turn device "off" - Suspend normal access to the 
device. MSS will request reinstatement upon 
maintenance completion. 

2. The IPLOS must be able to respond to MSS requests for 
"immediate" idle down and checkpoint system. 

6.1.3.13.3 REQUIREMENTS ON JOB MANAGEMENT 

1. Error/usage log data should be separate from customer logs* 
and not accessible by the customer. 
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2. All hardware errors detected on elements not in a 
maintenance state must be recorded. Multiple, occurrences of 
correctable errors may be logged as single entries including 
occurrence counts. Error logging is ootional for those 
elements in a maintenance state (oeing exercised by a CE 

• through MSS). 

3. The OS must log operating hours orevents (lines printed* 
cards punched* etc.) for each unit in the system to allow 
preventive maintenance actions to be determined. 

^. The OS must enforce maintenance action logging (i.e.* the 
C.E. must log repair data before returning system to the 
customer) . 

5. Maintenance log information will include date* time* and 
element i.d. (where applicable) as well as a variable 
amount of data including type ident i f icatioi. 

6. The maintenance log must be accessab le/purgeab le only by an 
operator of class CE#OP. 

7. The maintenance tog mast be recoverable across system 
restarts. 

8. The error/usage log should be periodically analyzed and the 
customer and/or C.E. notified if immediate maintenance 
action is required. The limits used to determine 
maintenance action should only be selectable by the C»E. 

9. Space requirements for the error/usage logs should be 
minimized. Data compaction techniques should be used so 
that log o verf low s do not occur between maintenance 
periods. 

10. * MSS "tasks" must be schedulable on the folloing basisi 

10.1 Time (elapsed) - the MSS task should execute at fixed 
intervals of time to perform such functions as 
maintenance log analysis* confidence level testing* 
etc. 

10.2 Time (of day) - the MSS task should be executed at 
certain times of the day to perform "scheduled" 
testing* analysis* etc. 

10.3 System idle - the MSS task should be executed during 
idle system periods. 

10.^ Event driven - the MSS task should be called into 
execution based on certain system cpnditions 
occurring • 
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10»5 Explicit call - the MSS tasK should be executed upon 
a level CE#OP operator console request* 

11. The MSS task must be able to execute in a "privileged" 
state which may include Monitor mode» specific ring 
numbersf segment numbers/descr iotorst etc. 

12. The MSS task must be able to create otier asynchronous 
"diagnostic" tasks and communication between tasks must be 
supported in a convenient and efficient fashion. 

6. 1.3.13. if REQUIREMENTS ON "data MANAGEMENT 

None 

None 

&f Jl.?.lliuitt2 RaayJL&^ ^nts qp fji^ Man^ggpignt 

None 

6il.f.3f.l^.titA3 S£i3yic£jB£filjs^aD,RgS9ni?-Man9g?fnsDt 

None 
6.1.3.13.^.^ Requirements on Block Mana g ement 
None 

!• A service processor "lORP" mechanism must be supported to 
enable request processing between the service processor and 
the MSS task. 

2» System I/O drivers must be caoable of supporting all 
diagnostic/maintenance featurest such asl 

- support of all H/W functions 

- activate/deactivate error checking logic 

- ut i I i zat ion of a H/H "echo" feature 

3. Equipment/Device tables must contain certain fault history 
information such as fault counts* fault thresholds* time 
stamp of last fault* etc. and device drivers must update 
this information where applicable. 



NCR/COC PRIVATE REV 06/13/75 



1 
2 
3 

«♦ 
5 
6 
7 
d 
9 
10 
11 
12 
13 
1^ 
15 
16 
17 
18 
19 
20 
21 
22 
23 
2^ 
25 
26 
27 
26 
29 
30 
31 
32 
33 
Zk 
35 
36 
37 
38 
39 
ffO 
kl 
t*Z 
kZ 
^^ 
^5 
^6 
^7 
i*8 
^9 
50 
51 
52 



tfl 
ADVANCED SYSTEM LABORATORY APDXE 

75/06/11 
IPLOS GOS - INTERNAL IPLOS REQUIREMENTS 

6.1.3.13.5 REQUIREMENTS ON PROGRAM MANAGEMENT 
None 

6.1.3.13.6 REQUIREMENTS ON STORAGE MANAGEMENT 

1. The IPLOS must maintain a pool of page frames which may be 
utilized by maintenance/recovery function without impacting 
system recoverab il ity . The page frames must be identifiable 
by service processor firmware referencing memory in a "dead 
OS" situation. 

6.1.3.13.7 REQUIREMENTS ON SYSTEM MANAGEMENT 

1. The OS should be caoable of performing a controlled power 
down sequence when it has detected that the electrical or 
cooling system is going down (electrical power loss* chilled 
water loss, etc. ) 

2. A linker/loader must be provided. 

3. Diagnostic/test libraries including IPL source and object 
code and firmware source and object must be maintainable on 
system mass storage utilizing "standard" library maintenance 
procedures. These libraries must be maintained utilizing 
checksums and/or other verification mechanisms. 

6.1.3.13.8 REQUIREMENTS ON DCS ^ " 

1. IPLOS must be able to accept a login of an operator of 
class CE#OP from any valid IPL supported terminal. 

2. Security considerations and command syntax must be the same' 
for all CE class operator consoles whether local or remote. 

3. System command language interpreters must enable processing 
of "NCS format" maintenance commands. 

6.1.3.1f*.l GENERAL REQUIREMENTS 

1. Compatibility Subsystems will take spec if ic advantage of the 
multiple monitor concept as outlined in 2.1.1 of the OS 
Structure document. 

2. Each CSS user of a particular CSS type; Cl» Cyber 3000* will 
be assigned to the singular monitor for that Subsystem 
type. 

3. The listed Record* File* LNS* Program ::oramunicat Ion and 

NCR/CDC PRIVATE REV 6/13/75 



1 
2 
3 

(» 
5 
6 

7 

8 

9 
10 
11 
12 
13 
1^ 
15 
16 
17 
18 
19 
20 
21 
22 
23 
2i» 
25 
26 
27 
28 
29 
30 
31 
32 
33 
Zk 
35 
36 
37 
38 
39 
kQ 
^1 
kZ 
hZ 

k5 

k7 

^8 

^9' 

50 

51 

52 



ADVANCED SYSTEM LABORATORY 

IPLOS GOS - INTERNAL IPLOS REQUIREMENTS 



APOXE 



75/06/11 



Program Execution requests seem entirely adequate for our 
objectives. 

6.1.3.1^.2 REQUIREMENTS ON SCL 

1. A command to invoke compatibi I ity operation is required* 

6.1.3.1^.3 REQUIREMENTS ON JOB MANAGEMENT 

1. Each logical target system will operate as a task. 

2. The signalling mechanism must be both efficient in operation 
and general in nature. 

3. The problem to be solved requires an IPL task (specifically 
the interface processor - CIP) to signal processes that are 
as diverse asJ 

a. Century interpreter, an IPL task limited to PI. 

b. 3000 interpreter, an alternate PI machine state on 
selected Pi's. 

c. Cyber interpreter, an alternate P2 machine state on 
selected P2's. 

>. The IPL emulator task, 3000L or Cyber must be assigned to 
the particular processor within the system with that 
interpreter capability. 

6.1.3.1^.^ REQUIREMENTS ON DATA MANAGEMENT 

1. Access to old data base management software and files from 
IPL users is required for the life of the migration task. 

2. The host IPL task must have knowledge of the structure of 
the target file in terms of the externalization of that 
file's address scheme (sequential, index sequential, or 
whatever else the parent corporations have supported). e 

3. OS services and access methods must be resident in two 
distinct virtual machine environments. 

§LiAtJii.lka.kjLL B£flJJlC£iD£t!l£-i2D-lQiyiDa-I!aQaa£ill£nl 

None • 

^tlt?f X^>^r2 — SaqulrgPLsr^ts gn File Mangq&rngnt 

None 
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6. 1.3. 1^ . ^. 3 Reoui reme fl ts on Record Man a gement 

None 
6. 1.3.1^»f».^ Reouiremehts on Block Mana g ement 

None . 

1. The requirement for device drivers for CDC or NCR non-IPL 
devices is an absolute requirement on the part of both 
parent companies. 

2. All devices (alien or IPL) dedicated to CSS are controlled 

by lOCB's through the same RSH protocol. 

3. Processor interpreters are also controlled by lOCB/IORP 
structures using the same RSM protocol. 

^. Assignment of processes and processes in particular 
processors of lOCB'S and lORP's is required. 

6.1.3.1i».5 REQUIREMENTS ON PROGRAM MANAGEMENT 

1. Restoration of alternate states to IPL processors upon 
return of control to those processes after interruption must 
be automatic and efficient. 

2. Code sharing between CSS subsystems is a requirement. 
6.1.3.1^.6 REQUIREMENTS ON STORAGE MANAGEMENT 

1. No instruction interpreter, either emulative or partial 
software will reserve real memory for its use. 

2. Most compatibility subsystems will utilize only a single 
mapped memory segment, although Cyber may utilize an 
additional virtual segment as ECS. 

3# All interpreters, firmware or software will utilize Map 
service in firmware for Map faults. A provision in" the 
exchange packages for all processors must be made to allow 
interrupting to IPL state for page services and restoration 
of the interrupted processor state upon completion. 

6.1.3.1^.7 REQUIREMENTS ON SYSTEM MANAGEMENT 

None 
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6,1.3.1if,8 REQUIREMENTS ON OCS 
None 

6,1.7 RAS REQUIREMENTS ON THE OPERATING SYSTEM 

G enera l Rea u 



Software is inherently no more reliable than 
hardware^ and in practice, is frequently less reliable* 

thereby limiting the reliability of the total system. This 
fact is recognized and accepted in the IPL where software 
procedures will be incorporated to repair tailing modules 
and ensure continued operation of the system. The key to 
this is d etect io n. Checksums* parity indicators and other 
techniques will be used to validate the integrity of key 
system tables and parameters. 



3. 



^. 



5. 



6. 



Hardware — Fayit Jlkt^sXiQn - 
hardware faults should be 
combinations of techniques! 



The following percentage of 
detectable using various 



75*/, detectable by hardware alone 
SOX detectable by hardware and softwa'^e combined 
95X detectable by hardware and diagnostics combined 
99X detectable by hardware* software, and diagnostics 
combined 

Fault Isolation ~ When a fault occurs, fault isolation 
procedures will be invoked to determine the extent of the 

damage. 



The OS should be able to isolate 80X of software 
the product responsible. 



faults to 



The OS must record 
Analysis programs. 



fault isolation data to support Log 



Rec onstruction - A class of software errors manifests itself 
by destroying part of the environment. Procedures will be 
provided in the IPL to reconstruct this environment when the 
condition is detected. This reconstruction will include 
repeating portions of the preceding job steps, if 
necessary. 

7. When tables and pointers have been corrupted, the IPL 
operating system will activate procedures to reconstruct 
them. If data in memory cannot be used for this purpose 
then back-up data carried on a particular device will be 
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8. 



used. Three facilities are provided on mass storage files 
to accomplish this. These facilities are specified in 
6.1.7.^.1 and 6.1.7.^.2. 

R econfiguration - When a permanent failure is detected, 
typically subsequent to retry, the system will be 
reconfigured to continue operation. A x:ombination of 
hardware and software techniques will" be used to achieve 
this, and the goals will be to make the process fully 
automatic. 
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10. Mq(juJ ar UalAQP *" The system will be separated into 
functional modules whch are then placed in water-tight 
compartments. That is the data bases on wiich each module 
operates will be clearly defined, as will interfaces with 
other modu I es. 

11. The IPL operating system will be constructed such that if 
one module fails in a catastrophic manner then the 
remaining modules will not be destroyed or affected. 

12. Both separation by function, and division into 
self-contained procedures help to isolate a probIe,m to a 
small code segment. This code segment will then be tested 
in a simulated environment, 

i3. pont ro I - Pri v i leged operat iona I modes will exist to allow 
the maintenance subsystem, under program control, to vary 
margins, to master clear, to set internal states, to 
override faults, etc. 

^^* S.Qypc e Le vel Maintenance - The IPL will use a comprehensive 
source level maintenance system, which will permit 
concurrent fault repair and evolutionary development. 

15. Diagnostic s - The objective of the IPL software diagnostics 
is to isolate d fault to a particular failing procedure. 
To achieve this they will operate in a simulated 
environment, if necessary. 
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!&• ll3l£aC5ljed oDzJULDS ^iSSnasJLLfiS • to assure the successful 

development and implementation of on-line diagnosticst it 
is necessary to have the diagnostics and their supporting 
software designed and developed by the operating system 
design team. It will not serve the success of the IPL to 
have these functions split off into separate 
organizations. Tne success of this integration will be 
evident by the presence of diagnostic and MSS sections in 
the operating system GOS • 

17« Sim u lat 1 on - An IPL environment simul ator will exist to 
provide a mechanism for fault isolation and repair of 
development software concurrent with customer operations. 

18. The O.S. must freeze features by DR time. 

19» Tes ting • All paths must be tested during Unit Test» and 
all interfaces must be tested in a separate Interface 
Test. 

>m ents oh SC L 



None 



1. 
2. 



E rf or Log - All errors detected on all devices op media will 
be recorded in the system maintenance file. 



All software errors 
maintenance file. 



will be recorded in the system 



§i. f Xt T^ h B5iayi£jtJDfiDl5-fi£i_lIal3-.li3Qa5fiJii^l 



!• U ser Exit? - Upon the initial detection of an error* or 
after standard system error procedures have been executed* 
the user will, be able to taKe an exit to invoke his own 
error recovery algorithms. 

2. £tiSS!iSi!I!LS " Tables controlling I/O transfers will be 
checKsummed* or individual entries will carry a parity 
indicator. 

3« CQrrobgratJQD - Certain functions such as request issue will 
be validated by corroborating data contained in the request 
against data contained in a separate software table. 

^. Permissions - Read* write and modify permissions are granted 
on an individual file' basis. The software will ensure 
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thatthese permissions are not breached. 

6. 1.7. if. 1 REQUIREMENTS ON VOLUME MANAGEMENT 

1« Devj,<;e Chaining - Each allocation unit of each file is 

. related to its successor and its predecessor. This data 

enables the reconstruction of device labels when necessary. 



6.1.7.^.2 REQUIREMENTS ON FILE MANAGEMENT 

i» D evice Labels - Device labels carry i'^formation on the 
allocation of all files on a given device. 

2» F i le Label s - File labels contain sufficient data in 
themselves to permit reconstruction of permanent file 
directories in the event that they have been destroyed. 

6. 1.7. if. 3 REQUIREMENTS ON RECORD MANAGEMENT 

None 
6.1. 7. if. if REQUIREMENTS ON BLOCK MANAGEMENT 

None 

6.1. 7. if. 5 REQUIREMENTS ON DEVICE DRIVERS 

1» S.tandgrd Er^p.c Recovery Algorithm s - Standards Hi|l be" 

defined for the IPL governing the recovery from al I device 
or medium errors. 

2. LocKs and Keys - Hardware locks will exist on all devices 
preventing a write on a device unless the correct software 
key has been issued to enable a write. 

3. Hrite C^r^taint y Checks - The IPL hardware logic at the , 
recording head will perform a write only if separate signals 
from the control ler and device driver indicate that a write 
was intended. 

^« P osi tion Certainty Checks - The hardware will ensure that a 

write will only take place wnere it was intended to occur* 
A validation check with the software address will be made to 
ensure this. 

6.1.7.5 Requirements onr Program M a nagem e nt 



None 
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6*1. 7>6 Reaulre m ents on Storage Hanaoement 1 

2 

3 

None ^ 

5 

7 

1. The ability is required to be able to load firmware from 9 

system devices via an 0«S. interface. 10 

11 

Zm All diagnostic development for the IPL will be of the 12 

on-line variety. The only off-line varieties are those 13 

which can be incorporated as a part of the system's . I oading 1^ 

procedure. In other words* if* because of a hardware 15 

malfunction» it is not oossible to load the operating 16 

system* then the system loading procedure mjst contain the . 17 

means by which it can determine (diagnose) the reasons for 18 

the failure to load. (Diagnostics should be to the plug-in 19 

board level.) Therefore* the system loader* before 20 

attempting to load or move on to the next process* must maKe 21 

a cursory examination of those facilities it is about to use 22 

andf if necessary, call in diagnostics to examine further 23 

questionable facill-ties. Zk 

25 

.fijLJUlAjB Sjgfl^JLnainsnls on PCS. 26 

27 
28 
!• C onsoles - The IPL will not have a dedicated maintenance 29 
console or oerators console. Normal remote terminals with 30 
keyboards and display facilities will be used for this 31 
purpose. A console will become either a maintenance or an 32 
operator console by software control. 33 
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